Signing and authentication devices and processes and corresponding products, notably for DVB/MPEG MHP digital streams

ABSTRACT

The present invention concerns a device and a process for signing digital streams, each of them comprising contents, related to audiovisual information, and a signaling. The device applies encrypting to selectively determined descriptors of the signaling, called authenticated descriptors, to obtain signature. The invention also concerns corresponding authentication device and process. Application to authentication of DVB/MPEG digital streams, notably for MHP.

This application claims the benefit, under 35 U.S.C. § 365 ofInternational Application PCT/EP02/14897, filed Nov. 8, 2002, which waspublished in accordance with PCT Article 21(2) on Nov. 27, 2003 inEnglish and which claims the benefit of International Procedure patentapplication No. EP02/05610, filed May 22, 2002.

FIELD OF THE INVENTION

The present invention relates to signing and authentication devices andprocesses, and to associated products, notably for DVB (Digital VideoBroadcasting)/MPEG (Moving Picture Experts Group) digital streams and inparticular for MHP (Multimedia Home Platform) standard.

BACKGROUND OF THE INVENTION

It thus relates notably to the field of digital television. The digitaltelevision environment includes the broadcast or streaming of differentsorts of data like audiovisual contents (typically MPEG audio/video),interactive contents, triggers, Program Specific Information (specificinformation about the sent programs, in brief “PSI”), ServiceInformation (complementary information enabling a receiver toautomatically configure and a user to browse in the services by means ofan EPG—Electronic Program Guide, in brief “SI”), Private Data, Signalingand so on. The information related to origins, destinations andstructuring of the contents (namely PSI, SI, and some private data) areusually integrated in the signaling.

These various data are usually distributed over MPEG-2 transportstreams, which consist of audiovisual streams transported in PES(Packetized Elementary Streams) and of other information (signaling,PSI, SI, interactive content . . . ) transported in MPEG-2 sections.Some digital broadcast networks and broadband networks are more or lessvulnerable to spoofing. Technically well equipped pirates can interceptdata, modify them and rebroadcast (or re-stream) those data in thenetwork. Terrestrial and microwave broadcast networks are morevulnerable than satellite or cable networks. The problem is thus tosecuritize digital data transmission over MPEG-2 networks.

In fact, some data items listed like audiovisual content, PSI and SI arepure broadcast content, so that their piracy is annoying for the user,but at least has not a financial impact for him. However interactiveterminals with a return channel can run t-commerce (television commerce)or home banking applications. Spoofing of such applications is then notonly very annoying for the user, but can also cost him a lot of money.

The authentication of data contents is already well known. Notably,document WO-99/49614 describes a method of authentication of data sentin a digital stream, in which the data are organized into a hierarchy ofat least one root directory unit, subdirectory unit and file unit. Thedata in a file are signed and an associated file authentication value isstored in the referring subdirectory unit. This file authenticationvalue is in turn signed and an associated subdirectory authenticationvalue is stored in the referring root directory. Other aspects of thisdisclosure relate to the authentication of a second root directory bygeneration of a second authentication value, and to the authenticationof data before encapsulation in tables or sections of a transportstream.

Also, document WO-99/62248 discloses a method implemented in aninteractive television system, for managing modules of interactivetelevision applications. This system transmits modules from a broadcaststation to a plurality of receiving stations, and the receiving stationshave module managers that store module requests and monitor the variouschannels for modules corresponding to the requests. In detailedembodiments, an application to be transmitted consists of a series ofmodules, one of which is a directory module. The latter contains anentry for each of the modules in the application, and enough informationto allow the receiving stations to access all the modules of theapplication. Further, an authentication mechanism may be applied in thereceiving stations for ensuring that the currently downloaded carouselsand/or modules are authentic.

Further interactive systems like the DVB Multimedia Home Platformspecify how to authenticate broadcast applications and they specify howto protect data contents that are transferred over a return channel.However, fraudulent operations still remain possible, since it ispossible to alter the signaling in an appropriate way so as to cancel,replace or add contents without any apparent discrepancy. It would thenbe tempting to provide for an authentication not only of the contents,but also of the signaling itself, as is done notably for streams builtaccording to the ATVEF (for Advanced Television Enhancement Forum)standard.

However, such a method causes specific difficulties for DVB digitalstreams, because streams are commonly re-multiplexed in networkhead-ends. Then, PIDs (Packet IDentifiers) or even the contents oftables like PMTs (for Program Map Tables, one table per programindicating the PIDs of the PES constituting that program, possibly inaddition to private information related to that program) risk to bemodified due to network requirements. This would mean calculating againall hash codes and signatures, what would involve giving to eachmultiplexer a private key to compute an appropriate signature. Now, thecost for providing each multiplexer with a certified key pair would behuge. That situation has discouraged skilled persons to develop such asignaling authentication strategy.

SUMMARY OF THE INVENTION

The present invention is related to a device for signing digital streamsintended to be transmitted via a communication network, adapted to DVBdigital streams authentication, notably for MHP applications, and makingcommunications much safer.

It concerns also a corresponding process, as well as a device, and anassociated decoder, and a process for authenticating digital streamsreceived via a communication network, and corresponding software anddigital stream.

Accordingly, the invention applies to a device for signing digitalstreams intended to be transmitted via a communication network, byproducing at least one signature to be incorporated in the digitalstreams, obtained from encrypting applied to the digital streams. Eachof those digital streams comprises several information entities, thoseentities including:

-   -   contents, related to at least audiovisual information, and at        least one signaling, made of an information set related to        origins, destinations and structuring of the contents, that        signaling being liable to be modified in networks due to network        requirements, containing essential data structures called        descriptors, and being built mainly by means of arranged        groupings called tables.

According to the invention, the signing device is intended to apply theencrypting to at least the signaling, and more specifically toselectively determined descriptors among the descriptors of thatsignaling, called authenticated descriptors.

So, by contrast with what would have been the natural solution ifsignaling had been signed, namely to apply authentication process tocomplete sections (which are sub-tables of the signaling, having alimited size), specific descriptors of the signaling are chosen forauthentication. A direct advantage of that surprising solution is thatit becomes possible for signing, to choose descriptors which remainuntouched by the re-multiplexing steps. Thus, protection againstmalicious modifications can be very efficiently put in practice, whileavoiding heavy complications in the authentication process, due tore-multiplexing in network head-ends.

Also, even when it is decided for signing to keep some descriptors whichare intended to be modified during re-multiplexing, it can be lighterand faster than if the complete sections had to be signed again, toprovide generating updated signatures taking into account the modifieddescriptors, in re-multiplexing equipments. Indeed, with a judiciouschoice of the modified descriptors, most information obtained at theemission level for signing can possibly be kept, notably in the form ofunchanged digest values resulting from hashing, and only minor part ofthe signing information has to be re-computed for signing.

By “audiovisual information”, it is meant audio and/or visualinformation.

Preferably, the digital streams are built according to DVB and MPEGstandards, and more specifically, according to MHP standard.

The signing device of the invention can be applied to the authenticationof any MPEG/DVB table, like notably for PSI tables: PMT, PAT (ProgramAccess Table, indicating for each sent program, the link between thenumber of the program and the PIDs of the PMT transport packets), CAT(Conditional Access Table, giving the PIDs of the PES carryingEntitlement Management Messages—EMM, in case of at least one programhaving a conditional access), and for DVB-SI tables: NIT (NetworkInformation Table), SDT (Service Description Table), EIT (EventInformation Table), TOT (Time Offset Table), AIT (ApplicationInformation Table), BAT (Bouquet Association Table). The signing devicecan also be applied to any MPEG/DVB private table based on the MPEG2system (ISO/IEC 13818-1) section syntax.

The signing device advantageously comprises means for enabling a user toselect the authenticated descriptors. That user is for example a memberof a broadcasting team. Then, either the identities of the chosendescriptors are incorporated into the streams, so that the receivers areinformed of the used descriptors as they receive those streams, or theyare beforehand agreed between the emitter and the receivers. Anothersolution is that the chosen descriptors are determined moresystematically, for example in a specific standard version.

Preferably, the signing device is intended:

-   -   to introduce the signature in at least one lowest level        signature descriptor in the digital streams,    -   and to further incorporate in the digital streams at least one        certification descriptor including certification data on that        signature,    -   and at least one higher level signature descriptor resulting        from applying encrypting to both contents of the lowest level        signature descriptor and the certification descriptor.

This is very interesting for safely and flexibly assuringinteroperability between various participants, like broadcasters andmanufacturers.

In practice, this can result in a Public Key Infrastructure (PKI), assoon as several levels are provided. Then, a root certificationauthority is established (for the highest level signature), as well asoptionally other certification authorities.

Preferably, the signing device comprises means for incorporating intothe digital streams, addresses of the authenticated descriptors. This isan efficient way to make the receivers aware of the used descriptors forsigning.

It is then advantageous that the incorporating means are intended tointroduce at least one hash descriptor in each of the digital streams.The hash descriptor comprises at least one digest value resulting fromthe application of a hash algorithm to at least one of the authenticateddescriptors and which is used for computing the signature. The hashdescriptor comprises also the addresses of the authenticated descriptorsused for computing that digest value. Such an achievement improves theauthentication efficiency, because it relies on transmittingintermediary results for computing the signature, and thus for checkingits authenticity.

More specifically, the incorporating means are preferably intended toarrange the hash descriptors in the digital streams according to a treestructure, at least one of the hash descriptors being computed from atleast one other of the hash descriptors having a lower level. Thatnested computation of the digest values enables to progressively computethe basic value from which the signature is finally obtained (namely,the root digest value), while ensuring taking into account all requiredinformation on the various authenticated descriptors.

The digest values have preferably a fixed size, as is usually done inthe existing hash algorithms.

Also preferred are the following embodiments with incorporating means,each table comprising at least one section having a limited size andbeing allocated a number, and each section comprising at least one loopsuccessively introducing descriptors in that section. Thoseincorporating means are advantageously intended to specify the addressof each of the authenticated descriptors belonging to at least one givenloop of a given section and having at least one occurrence numberrespectively for each of those loops, by mentioning at least:

-   -   that section number    -   and those occurrence numbers.

In that way, it is possible to identify efficiently and in a simple waythe identities of the used descriptors for authentication.

Other possibly transmitted information for addressing includes:

-   -   the version number of that section,    -   and/or the type of that section.

In a special achievement with the incorporating means, the signingdevice is advantageously intended to introduce the signature, andpossibly at least one of the digest values and of the certificationdata, in the form of private data into at least one specific section,such specific section being linked to the sections containing theauthenticated descriptors. That achievement allows to dissociate atleast some of the authentication information from the other signalingdata.

Thus, in a preferred embodiment, the specific section is intended tocontain the signature(s) and certificate data, advantageously in theform of signature and certificate descriptors, as well as a root hashdescriptor giving the root digest value and pointing to lower leveldigest values in other sections. This can be very advantageous, becausethe structure of DVB/MPEG-2 does not allow to place descriptors at thebeginning of a section, which are valid for the whole rest of thesection. Namely, all descriptors are somewhere in loops, which is thereason why top level descriptors cannot be sent directly with thesection.

In another embodiment with the specific section, not only thesignature(s) and certificate data and the root hash descriptor areplaced in the specific section, but also all other hash descriptors (forexample at the top level of that section). This is possible withDVB/MPEG-2, since the addressing mechanism allows to address descriptorsin tables directly.

The invention also concerns a process corresponding to the device above,preferably intended to be executed by means of any embodiment of thesigning device according to the invention.

Another object of the invention is a device for authenticating digitalstreams received via a communication network by checking at least onesignature incorporated in the digital streams. Each of those digitalstreams comprises several information entities, which include:

-   -   contents, related to at least audiovisual information,    -   and at least one signaling, made of an information set related        to origins, destinations and structuring of the contents, that        signaling being liable to be modified in networks due to network        requirements, containing essential data structures called        descriptors, and being built mainly by means of arranged        groupings called tables.

According to the invention, the authentication device is intended toapply authentication to at least that signaling, and more specificallyto selectively determined descriptors among the descriptors of thatsignaling, called authenticated descriptors, from which the signature iscomputed.

The authentication device is preferably intended to be applied todigital streams comprising signatures produced by a signing deviceaccording to the invention.

The invention is also related to a decoder, characterized in that itcomprises an authentication device according to the invention.

Another object of the invention is an authentication processcorresponding to the authentication device of the invention, preferablyintended to be executed by means of any embodiment of the latter.

The invention concerns also a computer program product comprisingprogram code instructions for executing the steps of the signing or theauthentication process of the invention when that program is executed ona computer.

The terms “computer program product” should be understood as embracingany materialization of a computer program, which could be directed notonly to storing supports (cassettes, disks . . . ), but also signals(electrical, optical . . . ).

The invention further applies to a digital stream comprising severalinformation entities, those entities including:

-   -   contents, related to at least audiovisual information,    -   and at least one signaling, made of an information set related        to origins, destinations and structuring of those contents, that        signaling being liable to be modified in networks due to network        requirements, containing essential data structures called        descriptors, and being built mainly by means of arranged        groupings called tables,    -   at least one signature being incorporated in the digital stream.

According to the invention, that signature is computed from thesignaling, and more specifically from selectively determined descriptorsamong the descriptors of the signaling, called authenticateddescriptors.

That digital stream is preferably produced by any of the embodiments ofclaimed signing device.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be better understood and illustrated by means of thefollowing embodiments, in no way limitative, with reference to theappended figures on which:

FIG. 1 is a diagrammatic representation of a signing device and acorresponding authentication device according to the invention;

FIG. 2 shows DVB/MPEG-2 elementary streams, including audiovisual andprivate data streams, and associated tables (PAT, PMT and AIT), andpoints out the links between the tables and the streams;

and FIG. 3 details some of the tables (PMT and AIT) of FIG. 2, inrelation to the elementary streams and to application information andapplication streams.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

An emitter 1 of digital streams 10 sends those streams 10 via a network5 to receivers 2, which include decoding capacities (FIG. 1). Theemitter 1 is typically intended to broadcast the streams 10, the network5 being for example a broadband or broadcast network, as notably acabled or satellite network. In another embodiment, the network 5consists in Internet. In the illustration case, the digital streams 10are constituted by DVB/MPEG-2 streams, which thus include notablycontents and signaling data related thereto. The signaling is builtmainly by means of tables and contains descriptors. The streams 10 canrely on the MHP standard.

The emitter 1 comprises a signing device 11 to sign the digital streams10 to be sent, and a user interface 15 which notably enables the sender,for example a broadcaster, to control the signing process. The signingdevice 11 is intended to sign the signaling, and not only the contents.It contains a selection module 12 for a user to select via the userinterface 15 some of the descriptors of the signaling, calledauthenticated descriptors, which are to be used for signalingauthentication. Thus, encrypting is applied to them to obtain theconcerned signature(s). The signing device 11 also contains anincorporating module 13, able to incorporate in the sent digital streams10, addresses of the authenticated descriptors.

Each of the receivers 2, as for them, comprises an authentication device21 able to check the signatures received, and notably the ones forsignaling authentication. The authentication device 21 is able to takeinto account the authenticated descriptors indicated in the streams. 10for authentication.

Particularly interesting examples will now be described. An importantentry point for signaling a digital television service (interactive ornot) is the PMT (Program Map Table) which is specified in the MPEG-2system standard (ISO/IEC 13818-1). In the case of signaling ofinteractive MHP applications, the PMT contains the location of thestream transporting the AIT (Application Information Table) and thelocation of the stream transporting the application code and data(pointer to the DSM-CC DSI message, DSM-CC designating the DigitalStorage Media—Command & Control standard, and DSI standing for“DownloadServerInitiate”, ISO/IEC 13818-6 International Standard), asillustrated in FIGS. 2 and 3. The technical achievements below enable toprotect the signaling data for interactive MHP applications, so that adecoding platform can check if it has not been modified over thetransport network. Moreover, the MPEG-2 systems standard prohibits thescrambling of the PMT, so that no scrambling is considered here.

The protection of signaling is based on hash codes, signatures andcertificates. The coding of these cryptographic messages is done by thespecification of three new descriptors, which contain respectively theobjects above:

-   -   hash_descriptor    -   signature_descriptor    -   certificate_descriptor.

The hash_descriptor fields are here introduced independently for eachsection to be individually authenticated, and we consider below such agiven section of a table, whether the latter is formed of severalsections or only one section. On the other hand, thesignature_descriptor fields apply to all the hash_descriptor fields in atable and the certificate_descriptor fields concern allsignature_descriptor fields in that table.

Specification of the Hash_Descriptor:

The hash_descriptor can be placed in loops of the AIT or of the PMT (orany other MPEG-2 table to be authenticated). More specifically, it islocated in each descriptor loop that contains descriptors to beauthenticated. The position in the loop doesn't matter, since thehash_descriptor includes a descriptor_address field which is able toaddress uniquely each descriptor.

The hash_descriptor contains a hash code, also called digest value,which is calculated over the descriptors on which descriptor_addresspoints to. In the case of the AIT or PMT, it includes only descriptorsthat follow in the same loop as the hash_descriptor. The pointeddescriptors can themselves consist in hash_descriptor fields, whichenables a recursive-like computation process.

The syntax of the hash_descriptor is the following:

hash_descriptor( ){ descriptor_tag 8 uimsbf descriptor_length 8 uimsbfdigest_count 16  uimsbf for(i=0 ; i<digest_count ; i++){ digest_type 8uimsbf descriptor_count 8 uimsbf for(j=0; j< descriptor_count; j++){descriptor_address 40  uimsbf } for (j=0; j< digest_length; j++){digest_byte 8 bslbf } } }

where “uimsbf” and “bslbf” stand respectively for “unsigned integer mostsignificant bit first” and for “bit string left bit first”.

descriptor_tag: labeling of the hash_descriptor.

descriptor_length: length of the hash_descriptor.

digest_count: this 16 bit value identifies the number of digest valuesin this hash descriptor.

digest_type: this 8 bit value identifies the digest algorithm, if any,used for the associated descriptors. The allowed values are given inTable 1, where MD-5 (MD for “Message Digest”) is defined in RFC 1321(RFC for “Request For Comment”; http://www.ieff.org/rfc/rfc1321.txt) andSHA-1 (SHA for “Secure Hash Algorithm”) is defined in FIPS-180-1 (FIPSPublication 180-1: Secure Hash Standard, National Institute of Standardsand Technology, 1994; http://www.itl.nist.gov/fipspubs/fip180-1.htm).

TABLE 1 Allowed values for the digest algorithm Value Digest lengthAlgorithm 0 0 Non authenticated 1 16 MD-5 2 20 SHA-1 Others Reserved

descriptor_count: this 16 bit value identifies the number of descriptorsassociated with the digest value. The value of this field shall begreater than zero.

descriptor_address: this is the generic address of descriptors insections, which is explained and detailed further on.

digest_length: this integer value gives the number of bytes in eachdigest value. It depends upon the digest type as indicated in table 1.

digest_byte: this 8 bit value holds one byte of the digest value.

Specification of the Signature_Descriptor

The syntax of that descriptor is as follows:

signature_descriptor( ){ descriptor_tag 8 uimsbf descriptor_length 8uimsbf signature_id 8 uimsbf signature_length 8 uimsbf for(i=0; i<N;i++){ signature specific data } }

descriptor_tag: labeling of the signature_descriptor.

descriptor_length: length of the signature_descriptor.

signature_id: this ID (for “IDentifier”) enables to have signatures frommore than one authority.

signature_length: Indicates the length of the following loop.

The field “signature specific data” contains the following ASN.1 ASN.1structure (for “Abstract Syntax Notation one” language), being acombination of BER (Basic Encoding Rules) and DER (DistinguishedEncoding Rules) structures:

Signature ::= SEQUENCE { certificateIdentifier AuthorityKeyIdentifier,hashSignatureAlgorithm HashAlgorithmIdentifier, signatureValue BITSTRING }

certificateIdentifier: as defined in the ITU-T X.509 extension (forInternational Telecommunications Union—Telecommunication StandardizationSection, Recommendation X.509: The Directory Authentication Framework,1997) related to the AuthorityKeyIdentifier field. It identifies thecertificate that carries the certified public key that is used to checkthe signature:

AuthorityKeyIdentifier ::= SEQUENCE { keyIdentifier [0] KeyIdentifierOPTIONAL, authorityCertIssuer [1] GeneralNames OPTIONAL,authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }

Implementations are not required to use a possibly present keyidentifier element (“keyIdentifier”) of the AuthorityKeyIdentifier. TheAuthorityKeyIdentifier structure contains both an authority certificateissuer identication (authorityCertIssuer) and corresponding authoritycertificate serial number elements (authorityCertSerialNumber).

The authoritycertIssuer field contains the field “directoryName”, whichgives the issuer name of the certificate that carries the public keyused to check the signature (and being thus equal to a field issuerNameused in MHP).

hashSignatureAlgorithm: this field identifies the used hash algorithm.As concerns the encryption algorithm required to compute the signature,it is already described in the certificate that certifies the associatedkey (in a SubjectKeyInfo field). Thus, only the identification of thehash algorithm is needed. The supported algorithms are MD5 and SHA-1, ofwhich identifiers are classically given by (see RFC 2379):

-   -   md5 OBJECT IDENTIFIER::={iso(1) member-body(2) US(840)        rsadsi(113549) digestAlgorithm(2) 5}    -   sha-1 OBJECT IDENTIFIER::={iso(1) identified-organization(3)        oiw(14) secsig(3) algorithm(2) 26}

signatureValue: value of the signature, which depends on choice for MHPspecification.

Specification of the Certificate_Descriptor:

That descriptor contains several certificates used recursively as inclassical PKI techniques. Notably, a leaf certificate is placed first inthe certificate_descriptor, and a root certificate, which is includedtherein for consistency only, is lastly indicated.

A file named CertificateFile contains all of the certificates in thecertificate chain mentioned in the certificate_descriptor, up to andincluding the root certificate. The profile for encoding the certificateis defined in ETSI. TS 102 812 V1.1.1 (for “European TelecommunicationStandards Institute, Technical Specification”).

The certificate_descriptor is specified as follows:

certificate_descriptor( ){ descriptor_tag 8 uimsbf descriptor_length 8uimsbf signature_id 8 uimsbf certificate_here_flag 1 bslbf reserved 7bslbf if(certificate_here_flag == 1){ certificate_cout 16  uimsbffor(i=0; i<certificate_count; i++){ certificate_length 24  uimsbfcertificate( ) } } }

descriptor_tag: labeling of the certificate_descriptor.

descriptor_length: length of the certificate descriptor.

signature_id: this ID links the certifications to a specific signature

certificate_here_flag: this is a bit field which, when set to “1”,indicates that the certificates are located in this descriptor.Otherwise, the certificates from an application should be used, a linkhaving to be defined.

certificate_count this 16 bit integer carries the number of certificatesin the certificate descriptor.

certificate_length: this 24 bit integer specifies the number of bytes inthe certificate.

certificate( ): this field carries a single “certificate” data structureas defined by ITU-T X.509.

In the case of an MHP platform, the same certification management asused for interactive applications can be used. Otherwise, mechanisms forcertificate management are specifically established.

Generic Addressing of Descriptors in MPEG/DVB Sections (Field“Descriptor_Address” in the Hash_Descriptor)

The addressing mechanism to address descriptors in MPEG and DVB tablesis now detailed. A variable length addressing mechanism can be used,which enables to store addresses in a more compact manner. However, inthe present embodiments, the addresses have a constant length of 40bits, which makes processing easier. Looking at current MPEG and DVBspecifications, we can identify three different types of sections.

The first section type (hereinafter denoted by “type0”) has the belowdescribed structure, the PAT, CAT and TOT tables being built with suchtype0 sections:

type0_section( ){ table_id . . . for (i=0; i<N; i++){ descriptor( ) }CRC_32 }with table_id giving an identification of the table and CRC standing for“Cyclic Redundancy Check”.

In the case of a type0 section, the bytes in the address have thefollowing meaning:

-   -   First byte: section number in the table;    -   Second byte: 0;    -   Third byte: 0;    -   Fourth byte: i(N), this byte addresses the descriptor in the        type0 section loop.

The second section type (hereinafter denoted by “type1”) has the belowdescribed structure, the SDT and EIT tables being built with such type1sections:

type1_section( ){ table_id . . . for(i=0; i<N1; i++){ . . . for(j=0;j<N2; j++){ descriptor( ) } } CRC_32 }

-   -   First byte: section number in the table;    -   Second byte: 0;    -   Third byte: i(N1), this byte addresses the outer loop of the        type1 section;    -   Fourth byte: j(N2), this byte addresses the inner loop of the        type1 section.

The third section type (hereinafter denoted by “type2”) has the belowdescribed structure, the NIT, BAT, PMT and AIT tables being built withsuch type2 sections:

type2_section( ){ table_id . . . for (i=0; i<N1; i++){ descriptor( ) } .. . for(j=0; j<N2; j++){ . . . for(k=0; k<N3; k++){ descriptor( ) } }CRC_32 }

In the case of a type2 section, the descriptor address needs five bytes:

-   -   First byte: section number in the table;    -   Second byte: i(N1), this byte addresses the first loop of the        type2 section;    -   Third byte: j(N2), this byte addresses the outer loop of the        second loop of the type2 section;    -   Fourth byte: k(N3), this byte addresses the inner loop of the        second loop of the type2 section.

Top Level Descriptors

By top level descriptors, we understand the certificate_descriptor andthe signature_descriptor fields, as well as the hash_descriptor fieldpointing to all other hash_descriptor fields in the section with thedescriptors to be authenticated (namely, the hash_descriptor containingthe root digest value).

In the present embodiment, those descriptors are sent in a specificsection, which is linked to the section containing the descriptors to beauthenticated. This linked specific section contains the same PID andTable_ID as the ones of the original section, but is differentiated fromthe latter via a special indicator, called “section_syntax_indicator”.For all DVB/MPEG defined sections, this section_syntax_indicator is setto one, which means that the section syntax follows the generic sectionsyntax. For the specific extension, the section_syntax_indicator is setto zero, which means that private data are present after a field givingthe length of the specific section (private_section_length). Thoseprivate data are specified in a way that they can contain the top levelinformation. The extension section has for example the followingstructure:

extension_section( ){ table_id 8 uimsbf section_syntax_indicator 1 bslbfprivate_indicator 1 bslbf reserved 2 bslbf private_section_length 12 uimsbf reserved 3 bslbf version_number 5 uimsbf certificate_descriptor() signature_descriptor( ) hash_descriptor( ) }

The field private_indicator, specified in ISO/IEC 13818-1 in thedefinition part of a private section, is a reserved bit for future uses,and the field “version_number” indicates to which version of table theextension section belongs to (see notably EN 300 468 V1.3.1—for“European Norm”).

EXAMPLE

The following example shows how the descriptors of an AIT can be usedfor signing. In this example, that whole table formed of severalsections is globally authenticated, instead of each section beingseparately authenticated as before. The first step is to select thedescriptors to be authenticated. The second step is then to calculatehash codes over those descriptors by using the MD5 digest algorithm. Ahash_descriptor, which is situated in each loop that contains at leastone authenticated descriptor, contains the addresses of thesedescriptors and the MD5 digest value of these descriptors. Since thehash_descriptor is addressable, it needs not have a specific position ina loop. In this way, hash codes can be generated for the AIT section.

The following figure shows the insertion of the hash_descriptor fieldsin a usual AIT structure (as defined in ETSI TS 102 812 V1.1.1):

Number of bits Identifier Application_information_section( ){ Table_id 8uimsbf Section_syntax_indicator 1 bslbf Reserved_for_future_use 1 bslbf. . . Common_descriptor_length 12  uimsbf for (i=0; i<N1; i++){ //hash_descriptor( ) // other descriptor( ) } . . .application_loop_length 12  uimsbf for (i=0; i<N2; i++) {application_identifier( ) application_control_code 8 uimsbf . . .application_descriptors_loop_length 12  uimsbf for (j=0; j<N3; j++){ //hash_descriptor( ) // other descriptor( ) } } CRC_32 32  rpchof }where “rpchof” stands for “remainder polynomial coefficients, highestorder first”.

The complete AIT table can consist of several sections, as any DVB/MPEGtable. After the hash codes of all sections of the table have beencalculated, the top level information has to be generated. In order todo this, a top level hash_descriptor taking into account allhash_descriptor fields of the corresponding table is computed (rootdigest value), where the above described descriptor addressing mechanismis used. The next step is to RSA-encrypt (RSA cryptographic algorithmstanding for Rivest-Shamir-Adleman) this top level hash_descriptor witha private key, corresponding to the public key that can be found in theleaf certificate of the corresponding certificate_descriptor. The resultof this RSA-encryption is the signature that is stored in thesignature_descriptor. The three top level descriptors are stored in a socalled extension section of the corresponding table. In the case of theAIT, the table ID is always 0x74, but the PID (Packet IDentifier) is thevalue that is listed in the PMT of the corresponding service. Theextension section containing the top level descriptors has the same PIDand table ID as those of the AIT to be authenticated, but thesection_syntax_indicator is set to zero:

extension_section( ){ table-id (0x74) 8 uimsbf section_syntax_indicator(0x00) 1 bslbf private_indicator 1 bslbf reserved 2 bslbfprivate_section_length 12  uimsbf reserved 3 bslbf version_number 5uimsbf certificate_descriptor( ) signature_descriptor( )hash_descriptor( ) }

The version number indicates to which version of table this extensionsection belongs to.

In a variant embodiment, all hash_descriptor fields are placed at thetop level in the extension_section.

In implementations, it is recommended to set thesection_syntax_indicator bit as “don't care” (meaning that thedemultiplexer dealing with the stream passes the bit throughindependently of its state “0” or “1”), so that the required DVB/MPEGsection itself and the extension_section pass the demultiplexer filter.In this way, the top level descriptors in the extension section aredirectly available and the authentication can be instantly done.

1. Device for signing digital streams for transmission via acommunication network, said device producing at least one signature forincorporation in said digital streams from encrypting applied to saiddigital streams, each of said digital streams comprising severalinformation entities, said entities including: contents, related to atleast audiovisual information, and at least one signalling, made of aninformation set related to origins, destinations and structuring of saidcontents, said signaling being modifiable in networks due to networkrequirements, said signaling containing essential data structures calleddescriptors, and being built mainly by means of arranged groupingscalled tables, wherein said device can includes means for applyingencrypting to at least said signaling, and more specifically toselectively determined descriptors among said descriptors of saidsignaling, called authenticated descriptors, that remain untouched byre-multiplexing steps in the network head-ends.
 2. Signing deviceaccording to claim 1, wherein said signaling resides in Program SpecificInformation, Service Information and some private data.
 3. Signingdevice according to claim 1, wherein said digital streams are builtaccording to DVB and MPEG standards.
 4. Signing device according toclaim 3, wherein said digital streams are built according to MHPstandard.
 5. Signing device according to claim 1, wherein saidencrypting is applied to the authentication of any MPEG/DVB table. 6.Signing device according to claim 5, wherein said device applies saidencrypting to the authentication of at least one of the followingtables: PMT, PAT, CAT, NIT, SDT, BIT, TOT, AlT and BAT.
 7. Signingdevice according to claim 6, wherein said device applies said encryptingto the authentication of at least one AIT table.
 8. Signing deviceaccording to claim 1, further comprising means for enabling a user toselect said authenticated descriptors.
 9. Signing device according toclaim 1, wherein said signature is introduced in at least one lowestlevel signature descriptor in said digital streams and said digitalstreams incorporate at least one certification descriptor includingcertification data on said signature and at least one higher levelsignature descriptor resulting from applying encrypting to both contentsof said lowest level signature descriptor and certification descriptor.10. Signing device according to claim 1, further comprising means forincorporating into said digital streams addresses of said authenticateddescriptors.
 11. Signing device according to claim 10, wherein saidincorporating means introduce at least one hash descriptor in each ofsaid digital streams, said hash descriptor comprising at least onedigest value resulting from the application of a hash algorithm to atleast one of said authenticated descriptors and being used for computingsaid signature, and comprising also the addresses of said authenticateddescriptors used for computing said digest value.
 12. Signing deviceaccording to claim 11, wherein said incorporating means arrange saidhash descriptors in said digital streams according to a tree structure,at least one of said hash descriptors being computed from at least oneother of said hash descriptors having a lower level.
 13. Signing deviceaccording to claim 10, wherein each table comprising at least onesection having a limited size and being allocated a number, and eachsection comprising at least one loop successively introducingdescriptors in said section, said incorporating means are intended tospecify the address of each of said authenticated descriptors belongingto at least one given loop of a given section and having at least oneoccurrence number respectively for each of said loops, by mentioning atleast said section number and said occurrence numbers.
 14. Signingdevice according to claim 10, wherein said device introduces saidsignature, at least one of said digest values and said certificationdata, in the form of private data into at least one specific section,said specific section being linked to said sections containing saidauthenticated descriptors.
 15. Process for signing digital streams fortransmission via a communication network, by producing at least onesignature to be incorporated in said digital streams from encryptingapplied to said digital streams, each of said digital streams comprisingseveral information entities, said entities including: contents, relatedto at least audiovisual information, and at least one signaling, made ofan information set related to origins, destinations and structuring ofsaid contents, said signaling being liable to be modified in networksdue to network requirements, containing essential data structures calleddescriptors, and being built mainly by means of arranged groupingscalled tables, wherein said process comprises a step of applying saidencrypting to said signaling, and more specifically to selectivelydetermined descriptors among said descriptors of said signaling, calledauthenticated descriptors, that remain untouched by re-multiplexingsteps in the network head-ends.
 16. Device for authenticating digitalstreams received via a communication network by checking at least onesignature incorporated in said digital streams, each of said digitalstreams comprising several information entities, said entitiesincluding: contents, related to at least audiovisual information, and atleast one signaling, made of an information set related to origins,destinations and structuring of said contents, said signaling beingliable to be modified in networks due to network requirements,containing essential data structures called descriptors, and being builtmainly by means of arranged groupings called tables, wherein saidauthentication device includes means for applying authentication to atleast said signaling, and more specifically to selectively determineddescriptors among said descriptors of said signaling, calledauthenticated descriptors, from which said signature is computed, theauthenticated descriptors remaining untouched by re-multiplexing stepsin the network head-ends.
 17. The device according to claim 16 whereinthe authentication device comprises a decoder.
 18. Process forauthenticating digital streams received via a communication network bychecking at least one signature incorporated in said digital streams,each of said digital streams comprising several information entities,said entities including: contents, related to at least audiovisualinformation, and at least one signaling, made of an information setrelated to origins, destinations and structuring of said contents, saidsignaling being liable to be modified in networks due to networkrequirements, containing essential data structures called descriptors,and being built mainly by means of arranged groupings called tables,wherein said authentication process comprises a step of applyingauthentication to said signaling, and more specifically to selectivelydetermined descriptors among said descriptors of said signaling, calledauthenticated descriptors, from which said signature is computed, saidauthentication process being preferably intended to be executed by anauthentication device according to claim 16.